In various existing network services, some network services have to restart the process in order to complete the restart or to reload configuration files. A typical example is HAProxy network service, which is often provided in many heavily loaded web sites. By adopting the SO_REUSEPORT option, HAProxy network service binds a new process to the same IP address and the same port as the original process, to wait for the new connections. Then, HAProxy network service sends a signal to notice the original process to shut down the socket on the listening port. However, during a short time period in which both the new and original processes are bound to the same IP address and the same port while the listening socket for the original process has not been closed yet, new connections may arrive. According to the implementation of SO_REUSEPORT in Linux kernel, the first packet of a new connection (Synchronize packet, SYN packet) may be assigned to any one of the original and new processes. If the SYN packet/packet is assigned to the original process while the listening socket for the original process is shut down, according to the TCP protocol, the server sends a TCP reset (RST) packet to the client to reset the connection, which may cause a normal connection to be reset unconditionally. Although the client may relaunch the connection, such a connection relaunch undoubtedly increases the time required for the entire data transmission and, meanwhile, increases the unnecessary burden to the network lines between the client and server. In addition to the above-mentioned HAProxy network service, many other network services also encounter the same problem, i.e., having to restart the process to complete the restart or to reload the configuration file, such as NginX network services, and the like.
To solve the above-mentioned problem in the network services, several solutions have been provided. One simple solution is to discard the received new SYN packet by configuring iptables rule when reloading the process. According to the TCP protocol, if the client does not receive SYN-ACK message, after a certain time period, the client will resend the SYN packet. Thus, the resent SYN packet may be successfully received by the new process which has been reloaded, thereby solving the above-mentioned problem. However, the disadvantage of this solution is that the client has to wait for certain time until the timeout occurs, before resending the SYN packet. The waiting time is often substantially long, for example, more than 1 second, while the time for reloading the process requires only tens of milliseconds. Thus, the new process which has been reloaded may have to wait, for example, about 1 second to receive the resent SYN packet. Therefore, in this solution, although the new connection is not going to be reset, a longer time delay may be introduced.
Another applicable existing solution is to utilize Linux flow control tools (TC). First, iptables are adopted to label the new incoming SYN packets, then the TC tool is adopted to temporarily cache these packets. After the process completes the reloading, the SYN packets are released. Compared to the previous solution, this solution may have a relatively short time delay. However, because the TC tool is only capable of controlling the outbound traffic, the corresponding application scenarios may be rather limited. For example, when the service process may work as a daemon process to monitor and receive the client connection, and the SYN packet is the incoming traffic, the solution based on TC tool may be unable to solve the above-mentioned problem.
Thus, techniques capable of providing a restart network service with advantages such as no time delay, available for both outgoing and incoming connections, and unrestricted application scenarios, etc., are highly desired.